> > So the script suid has to take > > preference. > > why?! i dont follow the logic. > Well, I see the logic in that one has to take precedence. Personally I would have gone for having the bins suidbits been honnored, as your bins do not reference the script i.e are not expected to know what perms it has, and futhur, are more likely to be dependent on any suid nature they may have. Also, in terms of time-precedence, obviously the scripts inode is looked at before the bins. There is a security issue here when you add groups. If the binrary is setgid & setgid and the scripts s[ug]id bits take precedence over the binary, then we can "knock off" either the sgid or suid of the binary and replace it with whatever we can put on the script. This could have far reaching consequences if the target binary expects BOTH a particular euid and egid to be secure (or neither). You might say that there is no issue here, because we can "add" groups. i.e put the binary's sgid into the suplimental gid list and our problem is solved. Almost. Your default file creation gid is still going to be the egid, and you can have only one. Likewise tests based on getegid() will give unpredicted/false results. Of course, to make things really interesting, we could have n files, comprised of n-1 setuid/setgid scripts and 1 setuid/setgid binary, with each script calling the next as its #! argument and the last calling the binary. ;-) Proff